Various mechanisms exist for recovering a platform from a bad boot. Often re-booting the platform is the first method attempted by the platform for recovery. Boot sector viruses attempt to infect the boot sector of the firmware, resulting in the operating system (OS) not being able to launch properly. Malicious, as well as inadvertent, actions may prevent the OS from loading properly. If the boot sector has been damaged, either by accident, or by malicious code, human operator intervention is often required to boot the platform. Some systems without directly connected media will boot from a remote boot device. In legacy systems, the boot vector, or pointer to the remote location, resides in non-volatile memory within the boot sector. If a system is without media, then the pointer to the remote boot device typically cannot be altered without removing the boot sector firmware and either rewriting or replacing it. If the boot vector is tampered with, then the platform cannot boot properly.
Often-times a platform's inability to boot may be a simple platform setting or corruption of boot target definition. In terms of legacy terminology, this might encompass a BBS setting corruption, a partition entry corruption, bad CMOS setting, etc.
Today, there is no consistent policy mechanism to provide persistent roll-back and policy recovery for a platform. In existing systems, there is no method for graceful platform degradation. Existing systems will typically either duplicate a flash block and force a total rollback or else do nothing (e.g., revert to manufacturer defaults).